The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
It is commonplace nowadays for a web browser (“client”) to access content that is stored on remote server by sending a request to the remote server's Universal Resource Locator (URL) and receiving the content in response. Web sites associated with very popular URLs receive an extremely large volume of such requests from separate clients. In order to handle such a large volume of requests, these web sites sometimes make use of a proxy device that initially receives requests and distributes them, according to some scheme, among multiple servers.
One such scheme attempts to distribute requests relatively evenly among servers that are connected to the proxy device. A proxy device employing this scheme is commonly called a “load balancer.” When successful, a load balancer helps to ensure that no single server in a server “farm” becomes inundated with requests.
When a proxy device receives a request from a client, the proxy device determines to which server, of many servers, the request should be directed. For example, a request might be associated with a session that is associated with a particular server. In that case, the proxy device might need to send the request to the particular server with which the session is associated.
A proxy device typically communicates with servers using a suite of protocols. For example, the proxy device may use the Internet Protocol (IP), Transport Control Protocol (TCP), and Hypertext Transfer Protocol (HTTP) in combination to communicate with a server. Some of these protocols are connection-oriented. Connection-oriented protocols typically require negotiating connection-related parameters between parties to the connection before the connection is “opened.” Data can be sent through the connection only after these parameters have been negotiated and the connection has been opened.
Parameter negotiation is often achieved through a “handshake” phase of a protocol. A handshake phase usually requires a significant amount of communication between the parties. When encryption is involved, a handshake phase also may require a significant amount of processing by the parties. Due to this communication and processing overhead, the transmission of substantive content between the parties may be delayed significantly.
After a connection has been opened between the proxy device and a particular server, the proxy device receives a request from a client and forwards that request to the particular server through the connection. The particular server sends a response to the proxy device through the connection. The proxy device forwards the response to the client. Several requests and responses might be sent through the connection during the course of a transaction between the client and the particular server. The combination of the client-to-proxy device connection and the corresponding proxy device-to-server connection is called a “proxied” connection.
The client-to-proxy device connection and the proxy device-to-server connection each may be a full TCP connection. A full TCP connection involves one TCP endpoint at the proxy device at one end of the full TCP connection, and another endpoint at the other end of the full TCP connection (at the client or server). Maintaining a full TCP connection involves significant resource overhead. In order for a proxy device to maintain full TCP connections, the proxy device needs to store and maintain, for each TCP endpoint at the proxy device, the parameters negotiated during the handshake phase for the corresponding full TCP connection. For each TCP endpoint at the proxy device, the proxy device stores these parameters in a separate TCP control block (TCB). Due to the storage required for TCBs and other overhead involved in maintaining a full TCP connection, a proxy device can allow only a limited number of full TCP connections at a time.
In order to permit a larger number of clients and servers to communicate through a proxy device concurrently, the proxy device can “unproxy” proxied connections. Unproxying is described in U.S. Pat. Nos. 6,006,268, 6,298,380, and 6,598,081. As discussed above, a proxied connection may involve two separate full TCP connections: a client-to-proxy device connection and a proxy device-to-server connection. Also as discussed above, each of these full TCP connections comprises two separate endpoints, one of which is maintained at the proxy device. To unproxy a proxied connection, the proxy device creates a connection block data structure (not a TCB) for each of the proxied connection's two TCP endpoints maintained at the proxy device. In each such connection block data structure, the proxy device stores (a) information that identifies the entity on the other end of the TCP connection (the client or server) and (b) a subset of the information contained in the corresponding TCP endpoint's TCB. With this information stored in the connection block data structures, the proxy device can dissolve the TCP endpoints maintained at the proxy device, leaving the TCP endpoints maintained at the client and server intact. The proxy device may free resources that were used to maintain the dissolved TCP endpoints' TCBs. Consequently, the proxy device may use those resources to establish other full TCP connections with other clients and servers.
The dissolution of the TCP endpoints at the proxy device does not sever the formerly proxied connection between the client/server pair that used the formerly proxied connection to communicate via the proxy device. Instead, after the dissolution, the formerly proxied connection persists as an “unproxied” connection. The server may send a packet to the client through the unproxied connection by sending the packet through the TCP endpoint remaining at the server. The packet contains addressing information that identifies the server and the client. The proxy device receives the packet and determines which connection block data structure contains information that matches the addressing information contained in the packet. After determining such a “matching” connection block data structure, the proxy device uses the information stored in the matching connection block data structure to (a) “translate” the packet's TCP sequence and acknowledgement numbers and (b) send the packet to the client. The client receives the packet at the client's remaining TCP endpoint. Although the TCP endpoints at the proxy device no longer exist, the unproxied connection appears, to the client and the server, to be the same as the proxied connection that the unproxied connection replaced.
Because a connection block data structure consumes considerably fewer resources than a TCB, the number of unproxied connections that a proxy device can maintain concurrently is significantly larger than the number of proxied connections that the proxy device can maintain concurrently. Additionally, because a proxy device is not responsible for guaranteeing reliable transport on an unproxied connection (the guarantee becomes the responsibility of the client and server), the proxy device is spared the burden of performing the operations needed to guarantee reliable transport on unproxied connections. Packets sent from servers to clients are not subject to load-balancing decisions, and can be transmitted using the relatively abundant unproxied connections. This allows the relatively scarce proxied connections to be reserved for transmitting packets from clients to servers, as such packets may be subject to a load-balancing decision by the proxy device.
Despite the benefits offered by unproxied connections, circumstances may arise in which an unproxied connection does not allow some desirable operations to be performed. In order to allow these operations to be performed, TCP endpoints might be needed at the proxy device after a formerly proxied connection has been unproxied. One approach to re-establishing TCP endpoints at the proxy device might involve the total dissolution of the existing unproxied connection and the formation of completely new, full TCP connections between the client/proxy device and proxy device/server pairs. However, such an approach would require additional handshake phases, which, as described above, are time-consuming. Furthermore, any new connections established in this manner would not appear to the client and the server to be the same as the former connections. The TCP endpoints at the client and the server would not be the same as the former TCP endpoints at the client and the server. As a result, the client and the server would carry the burden of adapting to use the new connections instead of the dissolved connections; transparency would be destroyed.
Thus, such an approach would be awkward and inefficient. A more elegant and efficient technique for re-establishing TCP endpoints at a proxy device after a connection has been unproxied is needed.